Programmable logic devices (PLDs) are a well-known type of programmable integrated circuit that can be programmed to perform specified logic functions. One type of PLD, the field programmable gate array (FPGA), typically includes an array of programmable tiles. These programmable tiles can include, for example, input/output blocks (IOBs), configurable logic blocks (CLBs), dedicated random access memory blocks (BRAM), multipliers, digital signal processing blocks (DSPs), processors, clock managers, delay lock loops (DLLs), and so forth.
Each programmable tile typically includes both programmable interconnect and programmable logic. The programmable interconnect typically includes a large number of interconnect lines of varying lengths interconnected by programmable interconnect points (PIPs). The programmable logic implements the logic of a user design using programmable elements that can include, for example, function generators, registers, arithmetic logic, and so forth.
The programmable interconnect and programmable logic are typically programmed by loading a stream of configuration data into internal configuration memory cells that define how the programmable elements are configured. The collective states of the individual memory cells then determine the function of the FPGA.
To program an FPGA to implement a circuit design, a user captures the circuit design using a well-known design capture tool, and then uses well-known software tools to convert the captured design into a device specific bitwise representation. The bitwise representation, commonly referred to as a configuration bitstream or configuration data, is typically stored in a non-volatile storage device such as a Programmable Read Only Memory (PROM) and written into the PLD using a predefined configuration process, or can be written into the PLD by an external device.
Note that the FPGA's configuration memory array is typically a volatile memory such as Static Random Access Memory (SRAM). Thus, when the FPGA is powered off, the configuration data stored in its configuration memory array is lost. Consequently, when the FPGA is again powered up, it must be re-configured using configuration data provided by the non-volatile storage device, as described above.
Consequently, a system including an FPGA typically includes a non-volatile memory storage device including the configuration data, and a bus or wire on which the configuration data is transmitted each time the system is powered up. The configuration data is therefore subject to interception from the bus or wire. Alternatively, the configuration data can be read from a programmed FGPA using a “readback” feature typically provided, or by using JTAG, for example. Potentially, an unscrupulous attacker can use this “pirated” configuration data to duplicate the system in an unauthorized manner. Additionally or alternatively, the configuration data potentially can be reverse-engineered to obtain the user design represented by the configuration data, and the user design could be analyzed or altered.
Various methods are known that can reduce the hazard of the unauthorized duplication of configuration data. For example, FPGA manufacturers routinely provide encoding and decoding for configuration data. The data stream is encoded using a key, e.g., by the same software that generates the unencrypted configuration data for the design. The encoded data is stored in a non-volatile memory device, from which it is downloaded to the FPGA and decoded on-chip using the same key. Therefore, the transmitted configuration data is encoded, and anyone who does not have the key used to encode the data cannot decode the data to reverse-engineer or alter the design.
For example, the Virtex-4™ family of FPGAs from Xilinx, Inc. incorporates a 256-bit encryption scheme using the Advanced Encryption Standard (AES) encryption algorithm. The 256-bit key is transmitted to the Virtex-4 device via a JTAG port, and is stored in the device in volatile memory, where the value is maintained using a small external battery. The key cannot be read from the volatile memory, and if the battery is removed the value is erased. Therefore, the key cannot be retrieved or duplicated from the device. If an encrypted stream of configuration data is loaded into the Virtex-4 device, but the encryption key used in generating the data stream does not match the decryption key stored on the device, the device does not function and behaves as if the configuration was not successful. The Virtex-II Pro™ family of FPGAs uses a similar system based on either the DES or the triple-DES algorithm, at the discretion of the user.
Encryption and decryption is an effective way of preventing the duplication and/or reverse-engineering of configuration data. However, this method does have some disadvantages. For example, the cost of providing the encryption/decryption functionality is borne by all users, not just those that desire the extra level of security. Additionally, there are extra hardware costs involved in programming and maintaining the keys. When the keys are SRAM-based, as in the exemplary FPGAs described above, an external battery must be provided. The keys must also be distributed and managed to maintain their secrecy, which carries a logistical cost.
Another copy protection technique involves using an attached secure device to authenticate a design. Authentication is different from copy-protection in that the configuration data is stored and transferred in an unencrypted form. Therefore, the configuration data can be duplicated at will. However, when configuration data is not properly authenticated, the design represented by the configuration data fails to operate in the target FPGA. One way of authenticating a design is to include an authentication key in a secure device coupled to the FPGA. For example, an authentication key can be stored in a secure EEPROM such as the Dallas Semiconductor/Maxim DS2432. A processor included in the FPGA checks the authentication key in the EEPROM against a known value programmed into the processor, e.g., by comparing a first hashed value obtained from the authentication key with a second hashed value obtained from the known value. The processor then either allows the user circuit to begin functioning (when they match), or disables the user circuit (when they do not match). The processor can be implemented in either hard-coded logic or soft logic in the FPGA. The disadvantages of using an attached secure device include the additional cost of the secure device, and the cost of the processor in the FPGA.
Another protection method involves the provision of so-called “Protection Registers” for processor code. For example, the Intel StrataFlash® memory device includes a 128-bit register comprising a 64-bit, factory-programmed, unalterable and unique identifier, and a 64-bit user-programmable field. The user-programmable field can be programmed, and then “locked” against future alteration. Therefore, this 64-bit field can be used to store, for example, an encryption or authentication key. The unique identifier can also be used, if desired, to provide the key for decrypting the processor code stored in the Flash memory device. The Atmel “C-” and “D-” series DataFlash® devices include a similar protection register. However, in both cases the encryption or authentication key has a known maximum number of bits (e.g., 128 bits for the StrataFlash device and 128 bytes for the DataFlash devices) and typically comprises either a single stored value or a simple concatenation of two values stored in the protection register. Given sufficient motivation, a key having these known attributes could potentially be reverse-engineered by a determined attacker, although the reverse-engineering process becomes more difficult with the larger key sizes available in some Flash memory devices.
Therefore, it is desirable to provide additional methods of providing authentication for user designs implemented in programmable integrated circuits.